When a large amount of data is stored in a database, such as when a server computer collects large numbers of records, or transactions, of data over long periods of time, other computers sometimes desire access to that data or a targeted subset of that data. In such case, the other computers can query for the desired data via one or more query operators. In this regard, historically, relational databases have evolved for this purpose, and have been used for such large scale data collection, and various query languages have developed which instruct database management software to retrieve data from a relational database, or a set of distributed databases, on behalf of a querying client.
It is often desirable to author source code for such management functions in a declarative programming language. Unlike imperative programming languages, declarative programming languages allow users to write down what they want from their data without having to specify how those desires are met against a given technology or platform. However, current models authored in a declarative modeling language usually go through a series of tools that transform declarative definitions into various concrete implementation artifacts. Moreover, once a model is authored, it is typically compiled by a compiler so as to generate specific compiled artifacts after ensuring that the source model is error free. It would thus be desirable to have an extensible intermediate file system representation that packages declarative source and all its transformed artifacts together along the way.
Most programming languages that use static compilers have similar needs. For example, in .NET, assemblies fulfill this need. In a native code world, C/C++ language compilers have a notion of libraries. From another perspective, the Open Packaging Convention (OPC) format, as used in Microsoft Office 2007®, also serves a similar purpose.
Accordingly, there is a need for a modern declarative model driven development environment that defines a declarative model and then transforms it into various artifacts during its lifetime. The above-described deficiencies of current relational database systems and corresponding packaging techniques are merely intended to provide an overview of some of the problems of conventional systems, and are not intended to be exhaustive. Other problems with conventional systems and corresponding benefits of the various non-limiting embodiments described herein may become further apparent upon review of the following description.